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Abstract.  The  SCR  (Software  Cost  Reduction)  toolset  contains  tools 
for  specifying,  debugging,  and  verifying  system  and  software  require¬ 
ments.  The  utility  of  the  SCR  tools  in  detecting  specification  errors, 
many  involving  safety  properties,  has  been  demonstrated  recently  in 
projects  involving  practical  systems,  such  as  the  International  Space  Sta¬ 
tion,  a  flight  guidance  system,  and  a  U.S.  weapons  system.  This  paper 
briefly  describes  our  experience  in  applying  the  tools  in  the  development 
of  two  secure  systems:  a  communications  device  and  a  biometrics  stan¬ 
dard  for  user  authentication. 


1  Introduction 

In  1978,  the  requirements  document  for  the  flight  program  of  the  A-7  aircraft 
[13, 14]  introduced  a  special  tabular  notation  for  writing  specifications.  Part  of 
the  SCR  (Software  Cost  Reduction)  requirements  method,  this  notation  was  de¬ 
signed  to  document  the  requirements  of  real-time,  embedded  systems  concisely 
and  unambiguously.  During  the  1980s  and  1990s,  SCR  tables  were  used  by  several 
organizations  in  industry  and  government,  e.g.,  Grumman  [19],  Bell  Laborato¬ 
ries  [15],  Ontario  Hydro  [21],  the  Naval  Research  Laboratory  [7],  and  Lockheed 
[5],  to  document  the  requirements  of  many  practical  systems,  including  a  subma¬ 
rine  communications  system  [7] ,  the  shutdown  system  for  the  Darlington  nuclear 
power  plant  [21],  and  the  flight  program  for  Lockheed’s  C-130J  aircraft  [5]. 

While  human  effort  is  critical  to  creating  requirements  specifications  and  hu¬ 
man  inspection  can  detect  many  specification  errors,  effective  and  widespread 
development  of  precise,  unambiguous  specifications  in  industry  requires  power¬ 
ful,  robust  tool  support.  Not  only  can  software  tools  find  specification  errors 
that  inspections  miss,  they  can  do  so  much  more  cheaply.  To  explore  what  form 
tools  supporting  the  formal  specification  of  requirements  should  take,  we  have 
developed  a  suite  of  software  tools  for  constructing  and  analyzing  requirements 
specifications  in  the  SCR  tabular  notation  [8].  The  tools  include  a  specifica¬ 
tion  editor  for  creating  the  specification  [9] ,  a  simulator  for  validating  that  the 
specification  satisfies  the  customer’s  intent  [8],  a  dependency  graph  browser  for 
understanding  the  relationship  between  different  parts  of  the  specification  [10], 
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and  a  consistency  checker  [11]  to  analyze  the  specification  for  properties  such  as 
syntax  and  type  correctness,  determinism,  case  coverage,  and  lack  of  circularity. 
The  toolset  also  contains  the  model  checker  Spin  [16],  a  verifier  TAME  [1],  a 
property  checker  based  on  decision  procedures  called  Salsa  [2] ,  and  an  invariant 
generator  [17],  all  of  which  may  be  useful  in  analyzing  specifications  for  critical 
application  properties,  such  as  safety  and  security  properties. 

The  utility  of  the  SCR  tools  has  also  been  demonstrated  in  several  projects 
involving  real-world  systems.  In  one  project,  NASA  researchers  used  the  SCR 
consistency  checker  to  detect  several  missing  assumptions  and  instances  of  ambi¬ 
guity  in  the  requirements  specification  of  the  International  Space  Station  [4] .  In 
a  second  project,  engineers  at  Rockwell  Aviation  used  the  SCR  tools  to  detect  28 
errors,  many  of  them  serious,  in  the  requirements  specification  of  a  flight  guidance 
system  [20].  In  a  third  project,  our  group  at  NRL  used  the  SCR  tools  to  expose 
several  errors,  including  a  safety  violation,  in  a  moderately  large  contractor- 
produced  specification  of  a  U.S.  weapons  system  [12],  Recently,  we  have  begun 
using  the  SCR  method  and  tools  to  analyze  specifications  for  security  properties. 
This  paper  briefly  describes  our  experiences  in  applying  the  SCR  tools  to  two 
secure  systems:  a  communications  device  called  CD  and  a  biometrics  standard. 

2  Applying  the  SCR  Tools  to  Secure  Systems 

2.1  Applying  SCR  to  a  Communications  Device 

COMSEC  (Communications  Security)  devices,  devices  which  manage  encrypted 
communications,  are  vital  to  the  correct  operation  of  U.S.  military  systems.  CD 
is  a  COMSEC  device  that  is  designed  to  provide  cryptographic  processing  for  a 
U.S.  Navy  radio  receiver.  In  addition  to  generating  keystreams  compatible  with 
another  cryptographic  device  and  supporting  multiple  channels  and  multiple 
cryptographic  algorithms,  CD  downloads  associated  algorithms  and  keys  into 
working  storage,  assigns  them  to  designated  communication  channels,  maintains 
the  association  between  an  algorithm  and  its  keys,  and  clears  algorithms  and  keys 
from  memory.  CD,  based  on  a  technology  for  implementing  COMSEC  devices 
in  software  as  well  as  hardware,  presents  a  new  challenge  in  the  development 
of  COMSEC  devices.  While  a  solid  base  of  experience  exists  for  implementing 
trustworthy  COMSEC  devices  in  hardware,  implementing  COMSEC  devices  in 
software  is  rare. 

To  provide  a  high  degree  of  assurance  in  the  correctness  of  CD’s  specifica¬ 
tion,  we  applied  the  SCR  tools  [18].  Our  results  suggest  that  applying  SCR  in  the 
development  of  COMSEC  devices  of  moderate  size  and  complexity  is  practical, 
effective,  and  low-cost.  In  approximately  one  person-month,  we  were  able  to  rep¬ 
resent  a  significant  subset  of  a  prose  requirements  document  for  CD  in  the  SCR 
notation  and  to  establish  that  the  SCR  specification  satisfies  a  set  of  security 
properties.  The  SCR  specification  of  CD  is  moderately  complex,  consisting  of  39 
variables  (17  input  variables,  three  auxiliary  variables,  and  19  output  variables). 
Figure  1  provides  a  natural  language  formulation  and  a  formal  representation  of 
each  of  the  seven  security  properties  that  we  verified  with  the  SCR  tools.  Because 


the  SCR  requirements  specification  of  CD  has  been  validated  using  simulation 
and  verified  to  satisfy  seven  critical  security  properties,  the  SCR  requirements 
specification  of  CD  can  help  guide  both  the  development  of  the  source  code  for 
CD  and  the  development  of  test  cases  for  evaluating  the  conformance  of  the 
source  code  with  CD’s  requirements. 


No. 

Description 

Property 

1 

If  CD  is  tampered  with,  then 
key  1  in  keybank  1  is  zeroized 

@T(mTamper) 

=>  cKeyBanklKeyl'  =  0 

2 

When  the  zeroize  switch  is  activated, 
key  1  in  keybank  1  is  zeroized 

@T(mZeroizeSwitch  =  on) 

=>  cKeyBanklKeyl'  =  0 

3 

No  key  can  be  stored  in  location  1 
of  keybank  1  before  an  algorithm 
has  been  loaded  into  the  first  location 
of  algorithm  storage  segment  1 

cKeyBanklKeyl  ^  0 
=>  cAlgStoreSegmentl  ^  0 

4 

If  backup  power  has  an  undervoltage 
when  primary  power  is  unavailable, 
the  CD  enters  either  Alarm  mode  or 

Off  mode 

@T(mBackupPower  =  undervoltage) 
WHEN  mPrimaryPower  =  unavailable 
=>  smOperation'  =  sAlarm 

OR  smOperation'  =  sOff 

5 

If  backup  power  is  overvoltage 
then  the  CD  is  in  Initialization, 

Standby,  Alarm,  or  Off  mode 

mBackupPower  =  overvoltage 
=>  smOperation  =  slnitialization 

OR  smOperation  =  sStandby 

OR  smOperation  =  sAlarm 

OR  smOperation  =  sOff 

6 

If  primary  power  has  an  overvoltage 
then  either  the  CD  is  in  Initialization, 
Standby,  Alarm,  or  Off  mode,  or  the  CD 
enters  Initialization  mode 

@T(mPrimaryPower)  =  overvoltage 
=>  smOperation  =  sStandby 

OR  smOperation  =  sAlarm 

OR  smOperation  =  sOff 

OR  smOperation'  =  slnitialization 

7 

If  primary  power  has  an  undervoltage 
then  either  the  CD  is  in  Initialization, 
Standby,  Alarm,  or  Off  mode,  or  the  CD 
enters  Initialization  mode 

@T(mPrimaryPower)  =  undervoltage 
=>  smOperation  =  sStandby 

OR  smOperation  =  sAlarm 

OR  smOperation  =  sOff 

OR  smOperation'  =  slnitialization 

Fig.  1.  Sample  properties  of  CD. 


2.2  Applying  SCR  to  a  Biometrics  Standard 

Positive  identification  and  authentication  of  personnel  is  a  critical  issue  for  many 
systems.  For  example,  U.S.  government  personnel  must  often  interact  with  the 
commercial  sector  in  situations  where  reliable  personnel  identification  is  critical 
for  limiting  access  to  sensitive  information  systems.  While  biometrics  technology 
addresses  the  critical  issue  of  personnel  identification  and  authentication,  prior  to 
deployment,  a  biometrics  product  must  be  certified  to  satisfy  published  assurance 
standards.  However,  the  labor-intensive  process  of  evaluating  and  validating  a 
biometrics  product  is  very  expensive  and  time  consuming.  One  way  to  reduce 
these  problems  is  to  use  automated  methods  to  support  product  evaluations. 
Applying  such  methods  should  not  only  lead  to  a  less  costly  and  shorter  process 
for  evaluating  biometrics  and  other  security  products  but  should  also  produce  a 
more  effective  process. 


To  assess  the  utility  of  the  SCR  method  and  tools  for  evaluating  a  biomet¬ 
rics  product  for  correctness,  we  applied  SCR  to  the  BioAPI  specification  [3],  a 
standard  which  defines  the  interface  between  an  authentication  device  that  uses 
biometrics  data  and  an  application  program.  The  goal  of  the  biometrics  API 
(application  program  interface)  is  to  enable  rapid  development  of  biometrics  ap¬ 
plications,  the  flexible  deployment  of  many  biometrics  devices  across  platforms 
and  operating  systems,  and  an  improved  ability  to  exploit  price  and  performance 
advances  in  biometrics.  From  the  BioAPI  standard,  we  produced  an  SCR  tab¬ 
ular  specification,  which  captures  the  behavior  of  six  major  operations  in  the 
standard.  The  SCR  specification  consists  of  20  variables:  10  input  variables,  one 
mode  class  variable,  and  nine  output  variables.  In  about  two  weeks,  we  were  able 
to  create  the  specification,  to  demonstrate  with  the  consistency  checker  that  the 
specification  contained  no  missing  cases  and  no  ambiguity,  and  to  verify  a  critical 
security  property.  The  goal  of  this  property  is  to  demonstrate  that  “the  system 
shall  successfully  authenticate  a  user  before  mediating  actions  initiated  by  that 
user.” 

3  Observations 

The  SCR  method  and  tools  contributed  to  the  specification  and  analysis  of  these 
two  systems  in  a  number  of  ways.  We  describe  these  ways  below: 

—  Requirements  Capture.  Developing  a  formal  requirements  specification 
from  the  prose  requirements  document  for  CD  was  difficult,  largely  because 
the  prose  document  was  organized  very  differently  than  an  SCR  specification. 
Moreover,  even  though  the  prose  document  was  high  quality,  a  number  of 
questions  about  the  required  behavior  of  CD  arose.  Two  SCR  tools  were  use¬ 
ful  in  correcting  and  extending  our  initial  SCR  specification  of  CD’s  required 
behavior.  First,  we  used  an  automatic  invariant  generator  to  construct  state 
invariants  from  the  draft  specification.  Analyzing  these  invariants  identified 
a  number  of  missed  requirements  and  some  incorrectly  captured  require¬ 
ments.  After  correcting  these  problems,  we  used  our  simulator  and  a  GUI 
builder  to  construct  a  simulation  of  CD.  Because  the  CD  program  manager 
was  very  busy,  he  did  not  have  the  time  to  review  our  specification.  Instead, 
we  showed  him  several  scenarios  using  our  CD  simulator.  By  viewing  the 
simulation,  he  was  able  to  quickly  identify  a  number  of  errors  in  our  CD 
specification  which  we  subsequently  corrected. 

—  Formal  Verification.  To  verify  the  seven  security  properties  listed  in  Fig¬ 
ure  1,  we  ran  TAME,  a  user-friendly  interface  to  the  theorem  prover  PVS. 
TAME  was  able  to  prove  four  of  the  seven  properties  directly.  To  prove 
the  remaining  properties,  TAME  needed  several  supporting  invariant  lem¬ 
mas.  Fortunately,  each  of  the  required  lemmas  belonged  to  the  set  of  state 
invariants  that  we  were  able  to  construct  with  our  invariant  generation  al¬ 
gorithm  [17]. 

—  Detecting  Incorrect  Properties.  We  were  unable  to  prove  that  the  CD 
specification  satisfies  an  eighth  security  property.  Although  we  tried  apply- 


ing  the  model  checker  Spin  to  the  CD  specification,  Spin  repeatedly  ran  out 
of  memory  due  to  the  large  state  space  of  the  CD  specification  and  thus  was 
unable  to  verify  or  refute  any  of  the  eight  security  properties.  The  false  prop¬ 
erty  was  detected  by  running  TAME  and  studying  the  problem  transitions 
returned  by  TAME.  By  experimenting  with  the  CD  simulator,  we  were  able 
to  construct  a  counterexample  that  ended  in  one  of  the  problem  transitions 
and  hence  demonstrated  that  the  eighth  property  was  false. 

—  Correct  Formulations  of  Security.  Formulating  a  correct  formal  state¬ 
ment  of  a  given  security  property  can  be  difficult.  In  our  work  on  the  biomet¬ 
rics  standard,  the  correct  formulation  of  the  security  property  (see  above) 
required  more  time  than  verifying  the  property. 

—  Code  Validation.  The  most  important  open  problem  is  how  to  validate  the 
source  code  that  implements  a  secure  system.  While  specifying  the  required 
behavior  of  a  secure  system  and  formally  proving  that  the  specification  sat¬ 
isfies  critical  security  properties  can  often  be  accomplished  in  a  reasonable 
time,  one  still  needs  to  demonstrate  that  the  source  code  operates  securely. 
One  approach  to  code  validation  is  specification-based  testing.  That  is,  one 
can  derive  a  set  of  test  cases  from  the  specification  and  automatically  use 
these  test  cases  to  determine  whether  the  source  code  satisfies  the  specifi¬ 
cation.  Some  initial  progress  in  developing  an  automatic  test  case  generator 
from  a  requirements  specification  is  reported  in  [6] . 
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